【レポート】Webアプリケーションに対する攻撃をAWS WAFで防御する #reinvent #SID342
こんにちは、臼田です。
今回はre:Invent 2017で行われたSID342 - Protect Your Web Applications from Common Attack Vectors Using AWS WAFについてレポートします。
本セッションはワークショップであったため、デモ環境が用意され、それを守るためのWAFルールを設定しました。
肝心の手を動かした内容については共有が難しいですが、その中で紹介された一般的なWebアプリケーションに対する攻撃から守るためのAWS WAFルール設定の考え方についての共有をメインにレポートします。
レポート
概要
一般的な脆弱性のために設定された基本的な緩和ルールを構築するプロセスを歩む7つの方法を共有します。これらのルールは一から作成すると、AWS WAFプログラミングモデルに精通し、アプリケーション固有のルールを記述することができます。特定のルールを記述するための段階的な解決策はありません。下記を参考に防御する対象に合わせた最良のソリューションを決定することをお勧めします。
具体的にどのようにAWS WAF及びその他のAWSサービスでWebアプリケーションを守るかについてはこちらの概要やUse AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilitiesを参照してください。
1. SQLインジェクションとクロスサイトスクリプティングの軽減
SQLインジェクション、クロスサイトスクリプティング、文字列と正規表現のマッチング条件を使用して、インジェクション攻撃やクロスサイトスクリプティング攻撃を軽減するルールを構築します。
次の点を考慮してください。
- あなたのWebアプリケーションは、（直接的または間接的に）エンドユーザーの入力をどのように受け入れますか。その入力がどのHTTPリクエストコンポーネントに挿入されるのですか？
- 入力形式に対してどのようなコンテンツエンコーディングの考慮事項を考慮する必要がありますか？
- フォールスポジティブに関して考慮すべき点は何ですか？
たとえば、アプリケーションが正当にSQL文を入力として受け入れる必要がありますか？
上記の質問から得られた要件は、あなたのソリューションにどのように影響しますか？
2.攻撃のための調査を制限する
Geo一致とIPアドレスの一致条件とともに文字列と正規表現を使用して、アプリケーションの公開コンポーネントに対する攻撃のための調査を制限するルールを作成します。
次の点を考慮してください。
- Webアプリケーションには、パブリックWebパスにサーバーサイドインクルードコンポーネントが含まれていますか？
- Webアプリケーションに、使用されていない公開されたパス（またはそのような機能を持つ依存関係）のコンポーネントがありますか？
- 管理用URL、ステータスまたはヘルスチェックのパスなど、エンドユーザーのアクセスを目的としないコンポーネントがありますか？
これらの要素へのアクセスを、既知の情報源（許可されるIPアドレスリスト、または地理的な場所）を利用してブロック、または制限することを検討する必要があります。
3.正常なリクエストを強制する
文字列と正規表現の一致、サイズ制約、およびIPアドレスの一致条件を使用して、不審なHTTP要求をブロックするルールを作成します。
次の点を考慮してください。
- Webアプリケーションに関連するさまざまなHTTPリクエストURLのサイズには制限がありますか？たとえば、100文字を超えるURIを使用していますか？
- アプリケーションが効果的に操作できない特定のHTTPリクエストコンポーネント（CSRFトークンヘッダー、承認ヘッダー、参照ヘッダーなど）がありますか？
アプリケーションにリクエストしてくるクライアントが正常であることを確実に保証できる仕組みを考えましょう。
4.ファイルインクルードとパストラバーサルの緩和
文字列と正規表現の一致条件を使用して、不要なパストラバーサルまたはファイルのインクルードを示す特定のパターンをブロックするルールを作成します。
次の点を考慮してください。
- エンドユーザーは、Webフォルダのディレクトリ構造をブラウズできますか？ディレクトリインデックスを有効にしていますか？
- アプリケーション（または依存関係コンポーネント）がファイルシステムまたはリモートURL参照の入力パラメータを使用していますか？
- 入力パスを操作できないようにアクセスを適切にロックしていますか？
- フォールスポジティブ（ディレクトリトラバーサルのシグネチャパターン）に関して考慮する必要があるのは何ですか？
パスへの入力に使用される関連HTTPリクエストコンポーネントが、既知のパストラバーサルパターンを含まないようにする必要があります。
5.異常の検出と軽減
あなたのWebアプリケーションに関して何が異常であるか？いくつかの一般的な異常パターンは次のとおりです。
- 一般的にリクエストが異常に増加している
- 特定のURIパスに対するリクエストが異常に増加した
- HTTPステータス 200以外のレスポンスが発生する異常に多い
- 特定のソース（IP、地理）からのアクセスが異常に多い
- 通常でないリクエストシグネチャ（リファラー、ユーザエージェント文字列、コンテンツタイプなど）
あなたはそのようなパターンを検出するための仕組みを備えていますか？もしそうなら、それを軽減するための規則を作ることができますか？
6.レピュテーションリスト、不正なリクエスト
レピュテーションリスト（ホワイトリストまたはブラックリスト）は、価値の低いリクエストの処理をフィルタリングして停止するのに適しています。これにより、運用コストを削減し、攻撃経路への露出を減らすことができます。
それらは例えば下記の要素で識別できます：
- 送信元IPアドレス
- ユーザーエージェント文字列
- ハイジャックされた認証トークンまたはセッショントークンの再利用
- よく知られている脆弱なソフトウェアパッケージであるパスへのリクエストを試みる(プローブ)
関連する条件を使用してそのような送信元IPのブラックリストを作成し、それらを照合してブロックするルールを設定します。 IPベースのブラックリストのサンプルは、あなたの環境にすでに存在しています。
レピュテーションリストは、第三者によっても管理されます。 AWS WAF Security Automationsでは、IPベースのレピュテーションリストを実装できます。
7.検出と監視
CloudWatchダッシュボードを使用して、保護層の監視システムを作成します。
このAWSブログでは、このプロセスの詳細を説明します。
使用できるメトリックのサンプルを次に示します。
- ブロックされたリクエストと許可されたリクエスト：許可されたアクセス（通常のピークアクセスの2倍）またはブロックされたアクセス（1,000以上のブロックされたリクエストを識別する任意の期間）のサージを受信した場合、CloudWatchを設定してアラートを送信できます。ここでのアイデアは、既知のDDoS（ブロックされた要求が増加する場合）または新しいバージョンの攻撃（要求がシステムにアクセスできる場合）を追跡することです。
- BytesDownloadedとUploaded：リソースを使い果たすために大量のアクセスを受け取る必要のないサービスをターゲットとするDDoS攻撃を特定する場合に役立ちます（例：検索エンジンコンポーネントが特定の1つのリクエストパラメータセットのMBの情報を送信します）。
- ELB SpilloverおよびQueue length：これらのメトリックを使用して、攻撃がインフラストラクチャに既に損害を与えているかどうか、および/または何らかの理由で攻撃者が保護層を迂回していているかを確認。
- ELB Request Count：上記と同じです。攻撃者が保護層やCloudFrontキャッシュをバイパスしているかどうかを確認することで、影響を特定できます。キャッシュヒット率を上げるためのルールを見直します。
- ELB Healthy Host：別のシステム状態チェックメトリック。
- ASG CPU使用率：攻撃者がCloudFront / WAFをバイパスするだけでなく、ELBレイヤーを迂回しているかどうかを識別し、攻撃の被害の影響を特定するためにも使用します。
まとめ
WAFのルール設定を考えるための体系的な学習につながる内容でした。
上記の考え方を元に各Webアプリケーションにあったルールを作成すると、より精度の高い防御が可能になると思います。
逆に、これらの運用が大変になるような場合もありますので、そういった場合には新しくリリースされたマネージドルールを利用することがおすすめです。
